Columbia Kermit/kermit.zip/newsgroups/misc.20000217-20000824/[e-mail] _Wed Apr 26 13:36:44 2000.msg

Internet Message Format | 2020-01-01 | 6KB

Return-Path: <[e-mail]>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
    by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA00723
    for <[e-mail]>; Wed, 26 Apr 2000 13:36:43 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA09537
    for <[e-mail]>; Wed, 26 Apr 2000 13:36:42 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id NAA04569
    for [e-mail]; Wed, 26 Apr 2000 13:10:59 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: Ishikawa <[e-mail]>
Subject: Re: Parity incorrectly reported, and RTS/CTS problem on Solaris 7 for
Date: Thu, 27 Apr 2000 02:09:03 +0900
Organization: RIMNET InterNetNews site
Message-ID: <[e-mail]>
To: [e-mail]

Frank da Cruz wrote:

>Thanks for the detailed report!  It's not conclusive but it looks like
>we can (and should) enable POSIX_CRTSCTS for all Solaris builds.  The
>only thing that bothers me is why nobody ever noticed flow-control
>failures before?  The Solaris version of C-Kermit has been using SVR4
>style RTS/CTS since 1992.

>So maybe the failures occur only in conjunction with 8-data-bits+parity,
>which is a new feature of C-Kermit 7.0.  Do you also get failures when
>you don't also set hardware parity?

(Any volunteers to test the untested combination yet?)

I tried a few test without using hardware parity. Still no luck. CRTSCTS is

not set in stty output of kermit-controlled tty port.

I am as puzzled as you regarding why the hardware flow-control
problem has not been not noticed by others before.

Here is my take on why this problem was not noticed before
by the many kermit users on Sun boxes, and if my guess is correct,
the problem didn't harm many people at all.

- Hardware flow-control is only necessary when
  CPU/OS is rather slow in comparison to the serial line speed.
  Thanks to the deep hardware FIFO queue in serial controller, and
  ever faster CPU, it seems that only under heavy use
  such as 115200bps on a 166Mhz pentium CPU under solaris 7 for x86
  using the 4KB packet length, the broken hardware flow-control
  problem becomes apparent.

  I wonder if this problem is noticeable on a Pentium 400 Mhz PC
  at 115200 bps connection at all.

  (Even on 166Mhz Pentium CPU PC, reducing the speed to 38400 bps
  works fine, and 115200 bps with 3 (three) KB packet length also works
  fine, too. So a lowly 166Mhz pentium PC works quite well.)

- Hardware Perception: Cable Unreliability.

  At 115200bps or when fast speed connection requires hardware
  flow control, the cable (poor) quality often becomes an issue.
  I suspect some people did encounter this broken rts/cts handling
  on Solaris platform (2.4 or later), but  when they saw that
  the reduced speed or reduced packet size  made the transfer
  succeed, they would have said  "Aha, bad cable/connection."
  and forgot the issue. (I would.)

- Solaris-specific Historical Reason

  If my reading of the messages is correct, solaris up to 2.3 did
  set RTS/CTS using ATT SysV semantics.
  The first broken version of kermit for Solaris 2.4 for x86
  didn't suffer much since the OS itself doesn't seem to have
  support for 115200 bps at all.
  Solaris 2.5.1 for sparc (on Ultra 1, at least) has
  no support for 115200 bps for serial tty input (split speeds for
  input and output. Output seems to have 115200 bps support.) and
  so presumably not many people tried these fast speed setting with
  kermit on this platform, either.

  So the chances are that the speed settings that would have made the
  broken RTS/CTS handling prominent only appeared in Solaris after
  powerful CPU had appeared and that the rts/cts control was not often
  required in practical settings.  (I have been using kermit to talk
  to Cisco router serial console port, but this is at 9600 bps.)

Practically speaking, for 115200 bps transfer to work, the cable must
be a high-quality short one. This means that the connection is quite
likely between two devices in the same room to begin with.  (Unless
the connection is interfaced to electrically isolated optical fiber
cable, etc..)
In such environment, LAN using inexpensive 10base-T connection
probably is more popular and is more fast indeed. So serial line
connection using Kermit in such a setting may be a rare attempt.
My current attempt is between a computer and a electronics gadget box
that speaks rs232c at various speeds with hardware flow control, and
this is why I was led to the rts/cts problem. Not many sysadmins
would have followed similar tracks.

Thus my theory is that not many people tried 115200bps direct
connection using kermit on solaris boxes to begin with.
RTS/CTS hardware flow control problem was not noticed because
it was masked by fast CPU and
deep hardware FIFO queue on PC,  or attributed to `bad cable', etc.

One exception to the `rare' use of 115200bps on solaris boxes is
ppp-connection using serial line.
Maybe the ppp (daemon and/or client) developers
may know something about this change of the way hardware flow-control
is enabled on various solaris versions because these developers
often have to handle external modem/ISDN TA (terminal adaptor) that are
connected directly to solaris boxes using very high-speed serial connection

such as 115200bps (or faster). But then again, one of these days, the
ISDN dialup routers with ethernet hub function made the serial
connection for this purpose obsolete, too.

PS: if we can return the failure code (-1) from
the att sysV semantics functions(s) to higher level
funtions, at least we can tell the user that something is woring by
printing
some meaningful  messages.
I am not familiar enough with the code to suggest a patch yet with
this regard.

Happy Hacking,

Ishikawa